home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / dhc / dhc-minutes-90may.txt < prev    next >
Text File  |  1993-02-17  |  5KB  |  121 lines

  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Ralph Droms/ Bucknell
  7.  
  8. This meeting of the DHC WG concentrated on the details of the proposed
  9. DHC protocol.  Specifically, the WG concentrated on the DHC protocol as
  10. used to initially configure the client's network layer.  The WG agreed
  11. that the following parameters should be configured:
  12.  
  13.    o IP address
  14.    o Subnet mask
  15.    o Broadcast address
  16.    o (Non-default or unusual) MTU - which may be required by some kinds
  17.      of network hardware
  18.  
  19. The WG has further agreed to base the DHC protocol on the BOOTP
  20. protocol, as extended by R. L. Morgan.  The agenda items for this
  21. meeting, then, included the definition of the following:
  22.  
  23.    o Client behavior within the protocol
  24.    o Server behavior
  25.    o Router or other forwarding agent behavior
  26.    o Protocol message formats
  27.  
  28. There are two primary problems to be solved by the client:  first, the
  29. client must decide which of possibly several sources of configuration
  30. information to use and second, the client must decide which IP address
  31. to use if given a range of addresses to choose from.  The client may get
  32. configuration information from a local cache or from a DHC protocol
  33. server.  If no configuration information is available (the ``genesis
  34. state''), the client should use a default configuration that allows
  35. interoperation with other clients on the same local net.
  36.  
  37. Greg Minshall presented an algorithm (included with this report) that
  38. was discussed at the meeting.  The genesis state was discussed at some
  39. length.  The WG agreed that a client in the genesis state should use a
  40. distinguished network number, defined so that routers will never forward
  41. packets with the distinguished network number.  This distinguished
  42. network number will allow interoperation between hosts on an isolated
  43. network, with no danger of genesis state packets leaking onto the
  44. internet if the isolated network becomes attached to an internet at some
  45. later time.  The WG also discussed problems with the transition from
  46. genesis state to normally configured state.  If an isolated net becomes
  47. attached while hosts are in genesis state, the hosts will either have to
  48. restart to obtain correct configuration parameters, or must be able to
  49. support interoperation with two logical nets on the same interface (both
  50. the genesis state network and the ``real'' network).
  51.  
  52. The WG discussed router behavior briefly.  We need to find out from
  53. router vendors about the details of existing BOOTP implementations so
  54. the WG can assess the impact of changes to the BOOTP protocol on
  55.  
  56.                                    1
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63. existing implementations and determine if a formal description of BOOTP
  64. forwarding agent behavior needs to be written.
  65.  
  66. The final point of discussion sparked some real controversy.  Before
  67. this meeting, the WG had discussed the IP assignment mechanism as an
  68. extension of the MIT and Morgan/BOOTP mechanisms, in which a client is
  69. provided a range of IP addresses from which it can choose a preferred IP
  70. address.  At this meeting, an alternative proposal was presented, in
  71. which BOOTP servers were presumed to have sufficient knowledge of the
  72. network configuration so as to be able to determine and allocate a
  73. single IP address to a client.  The presumption was that such a dynamic
  74. allocation mechanism would make the client code much simpler (in fact,
  75. existing BOOTP client code would work unchanged) at an acceptable cost
  76. in server complexity.  The dissenting opinion was that the increased
  77. server complexity was not worth the simplification in the client code.
  78.  
  79. As neither side had anything in writing, the WG had some difficulty in
  80. arguing the relative merits of the two mechanisms.  The WG chair has
  81. scheduled a meeting for June 8 in which several of the participants in
  82. the WG discussion will present written descriptions of the two
  83. mechanisms for discussion.
  84.  
  85.  
  86.  
  87.                                    2
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94. ATTENDEES
  95.  
  96.     Douglas Bagnall           bagnall_d@apollo.hp.com
  97.     Terry Braun               tab@kinetics.com
  98.     Andrew Cherenson          arc@sgi.com
  99.     Peter DiCamillo           cmsmainto@brownvm.brown.edu
  100.     Hunaid Engineer           hunaid@opus.cray.com
  101.     Roger Fajman              raf@cu.nih.gov
  102.     Metin Feridun             mferidun@bbn.com
  103.     Karen Frisa               karen@kinetics.com
  104.     Greg Hollingsworth        gregh@mailer.jhuapl.edu
  105.     Tom Holodnik              tjh@andrew.cmu.edu
  106.     Mike Horowitz             mah@shiva.com
  107.     Leo McLaughter            ljm@twg.com
  108.     Greg Minshall             minshall@kinetics.kinetics.com
  109.     Jeffrey Mogul             mogul@decwrl.dec.com
  110.     Michael Reilly            reilly@nsl.dec.com
  111.     Jeffrey Schiller          jis@athena.mit.edu
  112.     Tim Seaver                tas@mcnc.org
  113.     Ted Soo-Hoo               soo-hoo@dg-vtp.dg.com
  114.     John Veizades             veizades@apple.com
  115.     Steve Waldbusser          sw0l@andrew.cmu.edu
  116.     Jonathan Wenocur          jhw@shiva.com
  117.  
  118.  
  119.  
  120.                                    3
  121.